Each Arquillian test is associated with at least one deployment. The deployment is configured using a static method annotated with @Deployment that returns a ShrinkWrap archive. Here's an example:

@Deployment
public static JavaArchive createDeployment() {
    return ShrinkWrap.create(JavaArchive.class)
        .addClass(Greeter.class)
        .addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml");
}

Why is a deployment necessary?

If we want to be able to test inside the container, we need some way to get the code into the container. A container typically accepts some form of deployment. In most Java-based containers, these deployments are some sort of Java archive (jar).

ShrinkWrap provides a way to define a deployment archive (e.g., jar, war, ear) in Java using a fluent API. You use this API to create an deployment that's associated with the test case, which we call a "micro deployment". Arquillian can then use this object to stream the contents to the server in the most efficient way available.

The deployment archive is more than just a means to an end (getting code inside the container). There are several critical benefits to defining a deployment:

1. It allows you to isolate the classpath of the test – only those classes and resources inside the deployment are visible to the test

2. You can emulate or replicate a deployment scenario, which often triggers behavior (e.g., framework activation) that you cannot otherwise test

3. We can skip the build. Since the archive is assembled in Java, we're able to leverage the incremental compilation provided by IDEs

In summary, the strategy of using ShrinkWrap-based deployments gives you tremendous control over the code you're testing and quicker turnaround.